including updates to the utilities: gribmap, gribscan, gxtran, and gxps
19 February 1995, 22 February 1995, 1 March 1995, 25 May 1995, 15 June 1995
In a user-defined function adding the double quote around a char argument passes the string directly WITHOUT the usual conversion to lower case and removal of blanks, e.g.,
d grhilo(slp,F8.2,"This is the Label",0.25)
F8.2 gets passed as f8.2, but the second character would NOT be converted to thisisthelabel.
Correction of bug in automated search for scripts
The default for drawing the vector label for gxout vector in 1.5.1 was set to off. It is now set to on. To toggle:
set arrlab on|off
Allows SCALAR fields on the NMC UNSTAGGERRED eta model grid to be processed/displayed. Implemented for NMC. See doc/proj.doc
Allows 32-bit ieee float data, created on the cray or a BIG ENDIAN workstation (e.g., sun or sgi), to be read on the CRAY. Thus, one can create binary data on the cray and work with it on ANY OTHER platform (you have to add "big_endian" on the data descriptor file options card to work with the data on a little endian platform such as the PC). Implemented for NMC and FNMOC. ON THE CRAY use the following in the options card option cray_32bit_ieee, e.g., to work with a float data from a
sun on the cray:
change this .ctl file:
dset ^zg500.nmc_rnl.ll.sc.av.54.dat title NMC (V02)reanalysis (T62L28 / SSI) undef 1e20 xdef 72 linear 0 5 ydef 46 linear -90 4 zdef 1 levels 500 tdef 4 linear jan79 3mo vars 1 zg 0 0 hieght [m] endvars
to
:
dset ^zg500.nmc_rnl.ll.sc.av.54.dat title NMC (V02)reanalysis (T62L28 / SSI) options cray_32bit_ieee undef 1e20 xdef 72 linear 0 5 ydef 46 linear -90 4 zdef 1 levels 500 tdef 4 linear jan79 3mo vars 1 zg 0 0 hieght [m] endvars
The cray_32bit_ieee has no effect on a 32-bit platform. Further, if file is not opened if there is an invalid parameter in the options card.
Scaling in y was removed to yield a simple mean or average vice the weighted average when, e.g., mean(a,y=1,y=72)
On certain platforms, attempting to invoke a script in the GASCRP directory caused a segmentation fault and core dump. The bug was removed,
The new executables on the workstations are in:
Thus, grads is grads.151.sgi for the sgi's and grads.151.sun on the sun's and grads.151.alpha for DEC alpha workstations. Also, note that ONLY the SUN version has command line editing...
On the c90 and the ymp:
/wd2/wd20/wd20mf/grads app.151.cray
set xlpos offset side
where offset is the offset in " and side = b or t (bottom or top)
set ylpos offset side
where offset is the offset in " and side = r or l (right or left)
set arrlab xxx
where xxx is on to draw the vector label on a 'set gxout vector' plot or off to turn it off, the default is on and "sticks" (clear doesn't change it's state)
I have modified several .c and .h files to unify the code between the 32-bit and the 64-bit cray systems, i.e., there is now only ONE source. If the CRAY define variable in grads.h is set to 1 (i.e., #define CRAY 1), then the make will employ routines specific to the cray (there are only four C routines-gagby, gagbb, gapby and gapbb + two fortran for conversion between cray 64 bit floats and IEEE 32-bit floats). The value of CRAY for 32-bit platforms (big endian-sun,sgi,hp,ibm,next and little endian-dec,msdos(386+),linux) is 0.
For the readline library, READLINE is set to 1 in grads.h.
The whole process is controlled by the make.sh script which: 1) sets the appropriate parameters and location of libraries; 2) creates the makefile; and 3) executes the make itself. For example,
make.sh sun nmc
makes the whole distribution on the nmc sun's...
I have made GrADS 1.5.1 on the following platforms:
Contour labeling and gribmap were senstive to float->int casts on the cray. These casts have been adjusted to give consistent performance on 64-bit cray and 32-bit workstations.
To color fill between two lines:
set gxout linefill set lfcols 1 2 d a;b
I have added a number of features which simplify working with GrADS files and scripts. The most important one is command line editing which makes GrADS work like the tcsh or ksh. But there are others, namely:
When you start GrADS you now get, for example:
GX Package Initialization: Size = 11 8.5 !!!! 32-bit BIG ENDIAN machine version ga>
The !!!! line tell you that this version is 32-bit (i.e., data are 32-bit) and it was compiled for a big endian machine (the sun in this case). On the cray you get...
!!!! 64-BIT MACHINE VERSION (CRAYS)
If the readline library compiles on your system then the default prompt will be ga-> vice ga>. This indicates that command line editing is active...
I have only been able to compile the GNU free library "readline" on the sun, so you may not have it on your system. I'm hoping to get some help in resolving why it does work on the sgi's and the crays....
The source for readline and docs can be found by:
readline.tar readline.ps history.ps The library defaults to emacs mode but can be set up to run using vi syntax:
Here's a list of the commands I typically use:
ctrl-a go to beginning of line ctrl-e go to end of line ctrl-f go forward one char ctrl-b go backward one char ctrl-d delete the char ctrl-p recall previous line ctrl-n recall next line ctrl-r reverse search
You also get file name completion using the tab key. If there is more than one option, then double tab will list the available completions.
For example, suppose I'm running grads on div40-2 at FNMOC and I want to start looking for files to open... I type "open/ h" (sans the ") and get,
ga-> open /h
and hit two tabs and get:
h home home1 home2
GCC bogus603 gnu iqpops nmcobs roesserd GRIB cstrey grads lost+found pacek tsai Mosaic dh hamilton mendhall picardr witt NEWDBS dolan hout nicholso qcops
ga-> open /home1/GRIB/dat/nogaps.25. . . . nogaps.25.95021600.grb nogaps.25.95021912.grb nogaps.25.95021600.gribmap nogaps.25.95021912.gribmap nogaps.25.95021612.anal.grb nogaps.25.anal.ctl nogaps.25.95021612.ctl nogaps.25.anal.gribmap nogaps.25.95021612.grb nogaps.25.ls.mask.ctl nogaps.25.95021612.gribmap nogaps.25.ls.mask.dat nogaps.25.95021700.anal.grb nogaps.25.95021700.ctl and type "950217" to get ga-> open /home1/GRIB/dat/nogaps.25.950217 nogaps.25.95021700.anal.grb nogaps.25.95021712.ctl nogaps.25.95021700.ctl nogaps.25.95021712.grb nogaps.25.95021700.grb nogaps.25.95021712.gribmap nogaps.25.95021700.gribmap nogaps.25.95021712.anal.grb
and finally I open the 12Z data with 12.c, tab, return to open the file nogaps.25.95021712.ctl
I cannot guarantee these readline routines will always work, so I have added the -h option to the invocation of GrADS to turn it off...
Thus,
grads -h
will give you the standard,
ga>
prompt vice the command line editing prompt of
ga->
I use, what has become a de facto standard, ".ctl" as the extension for all my GrADS data descriptor files. So, I have modified the open command so that you don't have to type ".ctl",
e.g.,
open nogaps.25.95021700
vice,
open nogaps.25.95021700.ctl
I put all my GrADS "utility" scripts, such as cbarn.gs or font.gs, in one directory (e.g., /usr/local/grads/lib/scripts) so I know where to go if I need one in a script. To simplify running these scripts, I changed GrADS to first look in the current directory for the script and then if it can't find it append the ".gs" extension and try again. For example, suppose you are working on a test script called t.gs. You would run it in GrADS by,
run t.gs
Now you could,
run t
and it'll be executed.
If after the first two tries, the script still can't be located, then GrADS looks in the directory defined by the environment variable GASCRP. In the t(csh), for example,
setenv GASCRP /home1/grads/lib
or in ksh,
export GASCRP=/home1/grads/lib
Note the if the / is not added to the end of the directory name, but is automatically added. However, it'll still work if you
setenv GASCRP /home1/grads/lib/
d slp run /home1/grads/lib/cbarn.gs
simplies to,
d slp run cbarn
I have modified the GrADS I/O layer to handle different data structures and types.
The FIRST set were initially prompted by a need to work with the NASA GSFC DAO reanalysis and GCM output data in its own "phoenix" format and the Climate Analysis Center's Climate Diagnostic Data Base (CDDB). These options define GLOBAL characteristics of the data file......
In the data descriptor file the follow keywords have been added,
theader ttttt xyheader xxxxx
the number of header bytes which precede the data for each xy block (e.g., a 2-D lon/lat field). Using these features REQUIRES a DETAILED understanding of your data!!! GrADS will read the data file EXACTLY THE WAY YOU TELL IT TO! If you screw these up, your answers will be too....
I have written a FORTRAN program to AUTOMATICALLY build the .ctl file from the NASA phx format. Please contact me if interested.
The SECOND set allows control of the structure and format of EACH variable. In a GrADS data descriptor file each variable is defined using the following syntax,
vname nlevs units1,units2,unit3,units4 vdesc
These new features are invoked through the units? parameters according to the following syntax:
-1,xx,yy
Data where the variable and levels are transposed, e.g., (lon,lat,lev,var,time) vice the GrADS convention of (lon,lat,lev,var,time) For example, suppose you have four variables,
parameter (ni=144,nj=91,nk=18,nt=4) dimension u(ni,nj,nk),v(ni,nj,nk),t(ni,nj,nk),z(ni,nj,nk),dum(ni,nj) do n=1,nk call load(u,ni,nj,nk,n,dum) write(10) dum end do do n=1,nk call load(v,ni,nj,nk,n,dum) write(10) dum end do do n=1,nk call load(t,ni,nj,nk,n,dum) write(10) dum end do do n=1,nk call load(z,ni,nj,nk,n,dum) write(10) dum end do subroutine (a,ni,nj,nk,n,dum) dimension a(ni,nj,nk),dum(ni,nj) do i=1,ni do j=1,nj dum(i,j)=a(i,j,n) end do end do return
and the .ctl would look something like:
dset ^model.dat title some model data undef 0.10000E+16 options sequential xdef 144 linear 0 2.5 ydef 91 linear -90 2.0 zdef 18 levels 1000.000 950.000 900.000 850.000 800.000 700.000 600.000 500.000 400.000 300.000 250.000 200.000 150.000 100.000 70.000 50.000 30.000 20.000 tdef 4 linear apr85 1mo vars 4 u 18 0 u component from NASA model v 18 0 v component from NASA model t 18 0 temperature from NASA model z 18 0 geopotential height from NASA model endvars
But NOOOOO, in the NASA phx format, FOR THE UPPER AIR PROG VARIABLES ONLY, they,
do n=1,nk call load(u,ni,nj,nk,n,dum) write(10) dum call load(v,ni,nj,nk,n,dum) write(10) dum call load(t,ni,nj,nk,n,dum) write(10) dum call load(z,ni,nj,nk,n,dum) write(10) dum end do
Thus, variable and z are transposed or all variables are written out one level at a time....
To make matters trickier, for the UPPER AIR DIAGNOSTICS, the NASA format reverts the GrADS convention, so NOW we need to tell GrADS that the var-z transposed is no longer active...
To handle the upper air prog variables and THEN upper air diagnostics (e.g., cuheat and clouds), in the .ctl file would become:
dset ^model.nasa.dat title some model data from NASA undef 0.10000E+16 options sequential xdef 144 linear 0 2.5 ydef 91 linear -90 2.0 zdef 18 levels 1000.000 950.000 900.000 850.000 800.000 700.000 600.000 500.000 400.000 300.000 250.000 200.000 150.000 100.000 70.000 50.000 30.000 20.000 tdef 4 linear apr85 1mo vars 6 u 18 -1,10,1 u component from NASA model v 18 -1,10,1 v component from NASA model t 18 -1,10,1 temperature from NASA model z 18 -1,10,1 geopotential height from NASA model cuheat 18 -1,10,2 cumulus heating clouds 18 -1,10,2 cloud fraction endvars
This handles 4-D variables, i.e., all times for one variable written out in one chuck vice writing all variables at one time and then all variables at the next time. From the previous example, let's assume you now have data at nt times...
In a typical model you would,
parameter (ni=144,nj=91,nk=18)
dimension u(ni,nj,nk),v(ni,nj,nk),t(ni,nj,nk),z(ni,nj,nk),dum(ni,nj)
do l=1,nt
C
C run model and update the prog variables
C
call prog(u,v,t,z)
do n=1,nk
call load(u,ni,nj,nk,n,dum)
write(10) dum
end do
do n=1,nk
call load(v,ni,nj,nk,n,dum)
write(10) dum
end do
do n=1,nk
call load(t,ni,nj,nk,n,dum)
write(10) dum
end do
do n=1,nk
call load(z,ni,nj,nk,n,dum)
write(10) dum
end do
end do
And you'd have no problem reading the data in GrADS, but suppose you now read the model output and write out the u,v and t data DIFFERENTLY,
parameter (ni=144,nj=91,nk=18,nt=4)
dimension u(ni,nj,nk),v(ni,nj,nk),t(ni,nj,nk),z(ni,nj,nk),dum(ni,nj)
open (10...)
open (12...)
do l=1,nt
C
C write out all the u's
C
do n=1,nk
read(10) dum
write(12) dum
end do
do n=1,nk
read(10) dum
end do
do n=1,nk
read(10) dum
end do
do n=1,nk
read(10) dum
end do
end do
rewind 10
C
C now write out all the v
C
do l=1,nt
do n=1,nk
read(10) dum
end do
do n=1,nk
read(10) dum
write(12) dum
end do
do n=1,nk
read(10) dum
end do
do n=1,nk
read(10) dum
end do
end do
rewind 10
C
C now write out all the t's
C
.
.
.
While this seems UNNATURAL for a model, I have run into data sets like this with SEVERAL variables containing all times. The GrADS .ctl file would, your example, use
undef 0.10000E+16 options sequential xdef 144 linear 0 2.5 ydef 91 linear -90 2.0 zdef 18 levels 1000.000 950.000 900.000 850.000 800.000 700.000 600.000 500.000 400.000 300.000 250.000 200.000 150.000 100.000 70.000 50.000 30.000 20.000 tdef 4 linear apr85 1mo vars 3 u 18 -1,20 u component from NASA model v 18 -1,20 v component from NASA model t 18 -1,20 temperature from NASA model endvars
The sequential option is set because we wrote the data using unformatted (f77) I/O. Now suppose you want to use the template option in time. Use yy to tell GrADS how many times there are in each file, e.g.,
dset ^mydate.%y2.dat options sequential template . . . tdef 120 linear jan79 1mo vars 3 u 18 -1,20,12 u component v 18 -1,20,12 v component t 18 -1,20,12 temperature all endvars
yy=12 tells GraDS there are 12 months in each file.
This handles a pathological case were lon and lat are transposed or you have (lat,lon) vice (lon,lat) data. While this does "work" it is VERY INEFFICIENT because I didn't want to make a BIG change to GrADS internal I/O to handle this unusual case. However, it is useful for initial inspection and debugging and that's exactly how I used it. Here's an example .ctl file
dset ^latlon.dat title test case of data lat and lon are transposed a(j,i) vice a(i,j) undef 1e20 xdef 144 linear 0 2.5 ydef 73 linear -90 2.5 zdef 1 levels 1013 tdef 1 linear 00z1jan1995 12hr vars 1 u 0 -1,30 u comp endvars
The first case was to handle GMS data on a CD-ROM from MRI in Tsukuba, Japan. Here is the gms.ctl file:
dset ^I921110.Z12 undef 1e20 title GMS IR imagery during TOGA COARE fileheader 500 options yrev xdef 500 linear 130.05 0.1 ydef 300 linear -14.95 0.1 zdef 1 levels 1013 tdef 1 linear 00Z1nov1992 12hr vars 1 tb 0 -1,40,1 IR brightness temp - 100 K endvars
I have used the yy=4 options for integer data representing surface type...
I have added several new output (to terminal window) and calculation features to GrADS.
The built-in GrADS obs->grid analysis function "oacres" sets the initial value of the analysis grid to the arithmetic average of the obs in the area. For positive definate quantities like precipitation, this can produce an unrealistic analysis in regions of NO obs (e.g., no rain is better guess than average rain).
The call to oacres (stands for Cressman r**2 scan analysis) has the form,
d oacres(grid,obs,r1,r2,r3,...,r30)
where,
grid = is a grid to which the obs will be analyzed to obs =is the obs "grid" r1,...,r30 are the scan radii in GRID UNITS.
The default is:
or five radii. This is good for meteorological fields, but may not yield a desirable analysis for hydrologic fields which are not as continuous. To change the first guess, set the penultimate r to -1 and the last r to the desired first guess. For example,
d oacres(pr.1,pr.2,5,4,-1,-0.01)
would do an analysis of the pr.2 obs to the pr.1 grid with 2 scan radii of 5 and 4 grid units with a first guess of -0.01. oacress does not abort on errors in the parameters. Rather, the default oacres processing is applied.
There's a new gxout option called stat. When you
set gxout stat
and
display
or
d
something you get output to the terminal vice a plot or data output (e.g., set fwrite out.dat ; set gxout fwrite; d rh). Or the output goes to the script variable "result" which can be parsed inside a script (see the corr.gs GrADS script below) I have substantially enhanced the output to allow many statistical calculations to be made. Here's an example of opening up a global model file and looking at the 1000 mb relative humidity, statistically,
ga-> set gxout stat ga-> d rh Data Type = grid Dimensions = 0 1 I Dimension = 1 to 145 J Dimension = 1 to 73 Sizes = 145 73 10585 Undef value = 1e+20 Undef count = 0 Valid count = 10585 Min, Max = 0.0610352 100.061 Stats(sum,sumsqr,n): 787381 6.35439e+07 10585 Stats(sum,sumsqr)/n: 74.3865 6003.2 Stats(sum,sumsqr)/(n-1): 74.3935 6003.77 Stats(sigma,var)(n): 21.6761 469.854 Stats(sigma,var)(n-1): 21.6771 469.898 Cmin, cmax, cint = 10 100 10
Let's break it down:
Remember that if GrADS can't find any data it returns undefs. This is useful for checking if you gotten any data Valid count = 0 means no...
This should be fairly obvious, sum = the simple sum of all DEFINED points. sumsqr = sum of, in this case, rh*rh and 10585 is n.
gxinfo is handy when trying to find the plot area
ga-> q gxinfo Last Graphic = Line Page Size = 11 by 8.5 X Limits = 2 to 10.5 Y Limits = 0.75 to 7.75 Xaxis = Lon Yaxis = Val Mproj = 2
set lon -180 180 set lat -90 90
GrADS now has a new Graphic User Interface (GUI) widget type called "rband" for rubber banding to compliment the button widget. There are two modes: 1) box; and 2) line In box mode, when the user clicks and drags a box is opened and in line mode you get a line. To set up the rband,
set rband nn mode x1 y1 x2 y2
For example, suppose you did the q gxinfo above and you want to set up a box rubber band widget in the plot region only,
ga-> q pos
which freezes the system until the user clicks on the screen. After clicking and dragging you would get this kind of response
from GrADS:
Position = 2.13125 7.565 1 2 7.08125 2.19583 2.13 - x of the first corner of the box (x1) 7.56 - y of the first corner of the box (y1) 1 - which button was pressed: 1 - left 2 - middle 3 - right 2 - widget type (rband) 1 - button 2 - rband 7.08 - x of the second corner of the box (x2) 7.56 - y of the second corner of the box (y2)
q xy2w
to recover the lat/lon points...
The clear command does pretty heavy duty clearing of many of the GrADS internals and has now been expanded to limit what is cleared:
c events
flushes the events buffer (e.g., mouse clicks)
c graphics
clears the graphics, but NOT the widgets
c hbuff
You've asked for it and now you've got it! The following new GrADS functions:
mean
and
amean
have been added and work exactly like ave and aave respectively, EXCEPT that area weighting is disabled, i.e., the mean is a straight sum / # defined points.
gxtran is used to display GrADS meta files. Several new command line options are now available:
-i fname
fname is the name of the meta file
-r
Reverse black and white so you get your plot on white(black) background.
This is the same as the command line option in GrADS and allows you to set the geometry of the x window as you would in any other X app. The only difference is the space between -g and WWWW. The display window will be WWWW pixels wide HHHH pixels tall starting at X and Y on the screen.
Or animate the frames, i.e., do not pause between frames until the user hits a return in the command window.
For example,
gxtran -r -a -g 800x600+0 -i test.gm
would open a window 800x600 starting at the upper left corner of the screen and animate all frames (plots) in the file test.gm using a reverse background.
I have significantly upgraded Brian Doty's "gribscan" routine for extracting grid info from GRIB data files and now features: 1) grid output in ascii, floats, and/or grib; 2) more informative product/grid information; and 3) automatic "scanning" for GRIB records so that you don't have to know the physical layout of the data to scan it.
The -s? options can be strung together to output a very narrow set of fields. For example to ONLY output the 500 mb u component at t=48 use:
sp33 -sl500 -st48
The once "standard" 81-byte header in an NMC GRIB file contained the string GRIB. A big "duh" on you! Unfortunately, the same string is part of the GRIB indicator section itself! Thus, an automatic scan for GRIB to mark the start of the data will fail if the 81-byte header is present!
Thus, you have to KNOW that avn flux files HAVE the 81 byte header and run it as,
gribscan -h81
When in doubt (or failure) try -h81 -v.
-------------------------
Some samples:
gribscan -q -i eta.T12Z.PGrbF48 | grep 184 : 184, F ,135,108,100,0,100,0,1e+09, T ,1994,8,29,12,0,1,48,0, G ,104, BDTG, 94082912 184 - field # in the file F - field data 135 - param # 108 - level indicator 100 - level 0 - l1 byte 1 of level 100 - l2 byte 2 of level 0 - time range indicator 1e+09 - decimal scale factor T - time data follows 1994 - year 8 - month 29 - day 12 - hour 0 - min 1 - foreast time unit (hour) 48 - t=48 h forecast G - grid param follows 104 - NMC grid #104 BDTG - Base date-time-group (yymmddhh) follows
gribscan -d -i eta.T12Z.PGrbF48 | grep 184 :
PDS,184,104,135,108,100,0,100,1994,8,29,12,0,1,48,0,0,1e+09
same as above but arranged differently
gribscan -d -gv -bd -gd -i eta.T12Z.PGrbF48 | grep 184 :PDS,184,104,135,108,100,0,100,1994,8,29,12,0,1,48,0,0,1e+09,mconv,Horizontal moisture divergence,[kg/kg/s],GDS,5,147,110,-139.475,90.755,0.354 ,-0.268,-105.000,33536.000,0,1,0,BDS,12, -646.844,16170,4825059,26366
gribscan -og -sp135 -q -i eta.T12Z.PGrbF48 -o /wd2/wd20/wd20mf/tmp/eta.135
Writes out all GRIB message containing the 135 parameter to the file /wd2/wd20/wd20mf/tmp/eta.135.grb. A subsequent gribscan on eta.135.grb :
gribscan -q -i eta.135.grb :1, F ,135,108,100,0,100,0,1e+09, T ,1994,8,29,12,0,1,48,0, G ,104, BDTG, 94082912 2, F ,135,108,21860,85,100,0,1e+09, T ,1994,8,29,12,0,1,48,0, G ,104, BDTG, 94082912
source for gribscan.c is available on request........
To appreciate my improvements to gribmap, a little primer on how gribmap works is necessary.
When you set up a GrADS data descriptor file (e.g., the ".ctl" file), you are defining, external to the data itself, a structure, -- how many variables, how times in a file (or set of files with the template option), the spatial dimension or "shape" of the variables, etc. The "GrADS" format (floats, either 64-bit or 32-bit IEEE depending on platform) is so simple that the relationship between the data structure defined in the .ctl file can be calculated and stored in memory when the file is opened.
What makes GRIB so painful is that there is no relationship between the GRIB data and the bigger (4-D) structural context implied by the .ctl file. Hence, the need for a utility which "maps" between the GRIB data and the GrADS data description. How this actually happens in gribmap is that each field in the GRIB data file is read and its parameters (variable, level, time, etc.) extracted and then compared to all the variables at any of the levels/times/UNITS in the .ctl file until a match (hopefully) is found.
The new features of gribmap allow restrictions to be placed on this matching process.
However, the first improvement is version 1.5.1 is that it supports both GRIB0 and GRIB1.... (version 0 and version 1). Second the code now AUTOMATICALLY scans for character string "GRIB" vice having to worry about headers and what not (e.g., "junk" between the beginning and end of the GRIB message). That is unless you are NMC and put (duh) GRIB in the header. The default scan limit is 500 which can be changed via the command line option:
sxxxxx where xxxxx is the max number of bytes to search between records for GRIB.
To bypass the bytes before starting the scane process:
nicer output to verify what you are attempting to map...
when there is "junk" at the end of grib file the -e options disables the abort due failure to find grib records between data. Implemented to handle ECMWF GRIB files.
a match can only occur if the base time in the grib record is the same as the initial time in the .ctl file. This is used to pull out a forecast sequence (0, 12, 24, ... ,72 h) starting a specific time (e.g., 95010300)
where xxx is the forecast time in hours. In this case, a match occurs ONLY if the FORECAST time in the grib record matches xxx (hours). This is used to isolate a sequence of forecasts, e.g., all the 120 h forecasts verifying during the period 00z1jan1995 to 12Z2jan1995 from the MRF ensemble runs.
ignore the forecast time in setting up the match... This is useful in reanalysis where some of the diagnostic fields are "valid" at slightly different forecast time even though the share the same starting time. Here's a nice trick. To verify what is going on during the gribmap:
Another feature was added to map by the GRIB "time-range-indicator" specified in the .ctl file. This was put in for handling reanalysis data where the time-range-indicator distinguishes between monthly mean variances and means. Here's an example from reanalysis (flux.ctl):
dset /d2/reanal/nmc/output/grib.v02/month.flux.%y2%m2.grb undef 1.0e20 dtype grib index ^flux.gmp title NMC-NCAR reanalysis flux/gaussian grid quantities options yrev template xdef 192 linear 0 1.875 ydef 94 levels -88.54195 -86.65317 -84.75323 -82.85077 -80.94736 -79.04349 -77.13935 -75.23505 -73.33066 -71.42619 -69.52167 -67.61710 -65.71251 -63.80790 -61.90326 -59.99861 -58.09395 -56.18928 -54.28460 -52.37991 -50.47522 -48.57052 -46.66582 -44.76111 -42.85640 -40.95169 -39.04697 -37.14225 -35.23753 -33.33281 -31.42809 -29.52336 -27.61863 -25.71391 -23.80917 -21.90444 -19.99971 -18.09498 -16.19025 -14.28551 -12.38078 -10.47604 -8.571312 -6.666580 -4.761841 -2.857109 -0.9523697 0.9523621 2.857101 4.761833 6.666565 8.571304 10.47604 12.38077 14.28551 16.19024 18.09497 19.99970 21.90443 23.80917 25.71389 27.61862 29.52335 31.42808 33.33280 35.23752 37.14224 39.04697 40.95168 42.85638 44.76111 46.66580 48.57051 50.47520 52.37990 54.28459 56.18927 58.09395 59.99860 61.90326 63.80789 65.71249 67.61710 69.52165 71.42618 73.33064 75.23505 77.13934 79.04347 80.94736 82.85077 84.75322 86.65315 88.54195 zdef 1 linear 1 1 tdef 84 linear jan1985 1mo vars 54 ps 0 1, 1, 0,113 Pressure [Pa] tg 0 11, 1, 0,113 Ground Temperature [K] tas 0 11,105, 2,113 2m Temperature [K] tg300 0 11,111,300,113 Ground Temperature 300 cm down [K] tg10 0 11,112, 10,113 Ground Temperature 10 cm down[K] tg200 0 11,112,2760,113 Ground Temperature 10-200 cm down [K] tcll 0 11,213, 0,113 Cloud Temperature Low [K] tclm 0 11,223, 0,113 Cloud Temperature Mid [K] tclh 0 11,233, 0,113 Cloud Temperature High [K] tasmax 0 15,105, 2,113 Maximum temperature [K] tasmin 0 16,105, 2,113 Minimum temperature [K] uas 0 33,105, 10,113 10m u wind [m/s] vas 0 34,105, 10,113 10m v wind [m/s] huss 0 51,105, 2,113 2m Specific humidity [kg/kg] pr 0 59, 1, 0,113 Precipitation rate [kg/m**2/s] snm 0 65, 1, 0,113 Water equiv. of accum. snow depth [kg/m**2] clt 0 71,200, 0,113 Total cloud cover [percent] cll 0 71,214, 0,113 Total cloud cover [percent] clm 0 71,224, 0,113 Total cloud cover [percent] clh 0 71,234, 0,113 Total cloud cover [percent] albds 0 84, 1, 0,113 Albedo [percent] mrro 0 90, 1, 0,113 Runoff [kg/m**2] sic 0 91, 1, 0,113 Ice concentration (ice=1; no ice=0) [1/0] rss 0 111, 1, 0,113 Net short wave radiation (surface) [W/m**2] rls 0 112, 1, 0,113 Net long wave radiation (surface) [W/m**2] hfls 0 121, 1, 0,113 Latent heat flux [W/m**2] hfss 0 122, 1, 0,113 Sensible heat flux [W/m**2] tauu 0 124, 1, 0,113 Zonal component of momentum flux [N/m**2] tauv 0 125, 1, 0,113 Meridional component of momentum flux [N/m**2] mrso10 0 144,112, 10,113 Volumetric soil moisture content 10 cm down[fraction] mrso200 0 144,112,2760,113 Volumetric soil moisture content 10-200cm down [fraction] pevpr 0 145, 1, 0,113 Potential evaporation rate [w/m**/] gwdu 0 147, 1, 0,113 Zonal gravity wave stress [N/m**2] gwdv 0 148, 1, 0,113 Meridional gravity wave stress [N/m**2] gflux 0 155, 1, 0,113 Ground heat flux [W/m**2] rsuscs 0 160, 1, 0,113 Clear sky upward solar flux [W/m**2] rsutcs 0 160, 8, 0,113 Clear sky upward solar flux [W/m**2] rsdtcs 0 161, 1, 0,113 Clear sky downward solar flux [W/m**2] rlutcs 0 162, 8, 0,113 Clear sky upward long wave flux [W/m**2] rldscs 0 163, 1, 0,113 Clear sky downward long wave flux [W/m**2] crfss 0 164, 1, 0,113 Cloud forcing net solar flux at sfc [W/m**2] crfsa 0 164,200, 0,113 Cloud forcing net solar flux in atmos [W/m**2] crfst 0 164, 8, 0,113 Cloud forcing net solar flux at top [W/m**2] crfls 0 165, 1, 0,113 Cloud forcing net long wave flux at sfc [W/m**2] crfla 0 165,200, 0,113 Cloud forcing net long wave flux in atmos [W/m**2] crflt 0 165, 8, 0,113 Cloud forcing net long wave flux at top [W/m**2] rsds 0 204, 1, 0,113 Downward solar radiation flux at sfc [W/m**2] rsdt 0 204, 8, 0,113 Downward solar radiation flux at top [W/m**2] rlds 0 205, 1, 0,113 Downward long wave radiation flux at sfc[W/m**2] rsus 0 211, 1, 0,113 Upward solar radiation flux at sfc [W/m**2] rsut 0 211, 8, 0,113 Upward solar radiation flux at top [W/m**2] rlus 0 212, 1, 0,113 Upward long wave radiation flux at sfc [W/m**2] rlut 0 212, 8, 0,113 Upward long wave radiation flux at top [W/m**2] prc 0 214, 1, 0,113 Convective precipitation rate [kg/m**2/s] endvars
the fourth units parameter in the variable description is 113 for a mean, for variances:
. . . uas 0 33,105, 10,118 10m u wind [m/s] vas 0 34,105, 10,118 10m v wind [m/s] huss 0 51,105, 2,118 2m Specific humidity [kg/kg] . . endvars
If you don't understand the time range indicator, then consult the GRIB Gospel According to John (Stackpole that is; NMC Office Note 388).
The gxps utility converts GrADS graphics meta files (when "printing" in GrADS) to postscript. The new version solves all conversions problems in one utility using command line options:
The default is a b/w plot. There is no dependence on the ordering of the parameters
For example, to produce a color plot with a blackbackground from GrADS meta file test.gm:
gxps -c -r -i test.gm -o test.ps